mageforge:toolbar:inspector-state is dispatched by the inspector (see updateFloatingButton()), but this file comments that it’s “sync from toolbar” and then listens for it just to toggle the inspector button class. Consider updating the button state directly (e.g., toggle on this._inspectorFloatButton) and only dispatching an event if another component truly needs it, or rename/relocate the event so the direction is clear.

_appendInspectorButton() always creates/appends a new .mageforge-inspector-float-button when it finds the toolbar. If the inspector Alpine component is initialised more than once (or reinitialised via navigation/partial updates), this can lead to duplicated Inspector buttons. Consider reusing an existing button if present, or removing any previous instance before appending a new one.

updateFloatingButton() only dispatches a global event and doesn’t update the inspector button directly. Since the Inspector now owns _inspectorFloatButton, this could toggle the button’s active class directly and optionally dispatch a (clearly named) event for the toolbar to consume. Current naming/comment suggest the toolbar is being notified, but no toolbar listener exists in this PR.

This code assumes canvas.getContext('2d') always returns a valid context, but it can return null (e.g., if Canvas is unavailable/blocked), which would cause runtime errors in parseColor(). Add a guard for a null context and fail gracefully (e.g., skip the audit or treat colors as non-parseable).

The effectiveBackground() docblock says it “Returns null if no parseable background is found”, but the implementation always returns an RGB array (defaulting to white when nothing is found). Please update the comment/@returns to match the actual behavior (or adjust the function to actually return null as documented).

getShowButtonLabels() reads raw config via getValue() and compares strictly to the string '0'. Since getValue() returns mixed, non-string values (e.g. int 0/1) would make this behave incorrectly. Consider using isSetFlag() for this Yes/No config path (and rely on config.xml for the default).

The close button HTML uses title="Close & deactivate all" inside an innerHTML template. The & should be escaped (&) to keep the HTML valid and avoid entity parsing issues; alternatively set the title via setAttribute.

The audit’s visibility filter checks style.opacity === '0', but browsers may return '0.0'/'0.00'. This can include fully-transparent images in results; use a numeric check for opacity.

The inspector button no longer gets a theme attribute / .mageforge-inspector wrapper class (it’s now just .mageforge-inspector-float-button). inspector.css theme overrides target .mageforge-inspector[data-theme="..."] .mageforge-inspector-float-button, so in light/auto mode the button won’t pick up the intended styling. Consider propagating data-theme to the button (or re-adding the mageforge-inspector class) or updating selectors to match the new toolbar embedding.

getContext('2d') can return null; _colorCtx is used unguarded (e.g. clearRect, fillStyle), which would throw and break the audit in that scenario. Add a null check and fail the audit gracefully (e.g. show an error badge) when the canvas context isn’t available.

Visibility check uses style.opacity === '0', which misses equivalent computed values like 0.0 and can produce false positives/negatives. Use a numeric check (e.g. parseFloat(style.opacity) === 0) for consistency with the lazy-load audit.

The audit menu is min-width: 350px, which will overflow on narrower viewports (many phones are <350px wide) and can cause horizontal scrolling/clipping. Consider using a responsive width (e.g. width/max-width based on 100vw) while keeping a comfortable desktop width.

In the mobile breakpoint the burger button is forced to width: 32px but the label remains visible and padding/gap remain, so the content will likely overflow or be clipped. Either hide .mageforge-toolbar-burger-label at this breakpoint or adjust sizing/padding so the button can still accommodate the text.